As system speeds increase, the use of PLL and DLL devices is becoming prevalent throughout the system. Some of the uses of these devices include clock distribution, clock/data recovery, aligning data and clock on parallel interfaces, and providing effective data capture on serial interfaces.
PLLs inherently require time to “acquire lock” whenever the PLL is reset, powered up, or undergoes a rapid input frequency change. This may present a problem.
Within systems, it is possible for every interface, or bus to have a PLL device on the input, output or both. When systems are interconnected, it is likely that there will be several layers of PLLs connected, each relying upon the previous PLL for its input. This may present a problem.
For example, FIG. 3, generally at 300, shows a simplified block diagram of a system. The “Master system clock” (such as at 302) could be a simple PLL and crystal oscillator combined to generate a clock across a board or larger system. The “subsystem clock” (such as at 304) could be something like a processor or ASIC (application specific integrated circuit) that receives the Master system clock and generates one of its own from that clock through a PLL. The ASIC may have a memory bus that uses a source synchronous clock which is sent to a memory device (Remote system clock, such as at 306) where it enters a PLL and the PLL regenerates the clock for local usage and data capture on the bus. Other systems may extend for several more layers.
Such systems of interconnecting clocks (as illustrated generally in FIG. 3) with each clock relying upon the previous clock for input is in usage. The use of PLLs on interfaces is becoming more common as speeds increase and precise timing is required. PLLs upon power up, reset or a frequency change require a “lock time” to acquire the new frequency and stabilize the PLL. The PLL must search for its final operating frequency and then perform phase corrections until final lock is achieved. For example, as shown in FIG. 3, the Master system clock (such as at 302) is required to first achieve stability before the Subsystem clock (such as at 304) may acquire stability. During the Master system clock (such as at 302) stabilization, the clock being sent to the Subsystem clock (such as at 304) is not stable, thus delaying the stabilization of the Subsystem clock (such as at 304). Further extending the problem to lower systems (e.g. systems further down the clock chain), the Remote system clock (such as at 306) is unable to achieve stabilization until both the Master system clock (such as at 302) and the Subsystem clock (such as at 304) have achieved stability (e.g. sequentially in order). The remote system clock (such as at 306) may have further problems because the subsystem clock (such as at 304) may have been operating at an extreme, undesired, or errant frequency during the stabilization process that may have upset the downstream remote system clock (such as at 304). This may result in the system being clocked by the remote system clock (such as at 306) operating improperly, operating outside design parameters, etc. This may present a problem.
The use of source synchronous clocks in high-speed systems may extend the number of layers of PLLs in a system to a very large number with each depending upon the previous for stability before it can acquire its own stability. This may present a problem.
Slow PLL lock time, as noted, may present problems. The use of multiple, cascaded PLLs may exacerbate the problems. For example, problems which may be caused by slow PLLs lock time include, but are not limited to, the following:
1) System boot time delay. After power up or reset, each PLL waits for lock and subsequent PLLs rely upon the previous PLL for lock before they can acquire their own lock. Boot times can become extensive.
2) Performing a frequency change with a PLL requires a PLL to undergo a new search and lock. For example, several situations that may require a frequency change include system testing and link failure where a new (such as lower or higher) frequency is needed.
3) A disconnected system may have no clock. A PLL with no input reference clock may produce an unstable or unknown output.
Thus slow PLL lock times may present a problem.